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[57] ABSTRACT 

A programmable controller for operating a machine to 
carry out programmed functions includes a plurality of 
program processors. Each of the program processors is 
operable to execute simultaneously a different user con- 
trol program that directs the operation of the machine 
to perform specific functions. Each of the program 
processors includes a memory for storing the user con- 
trol programs and function chart data. The function 
chart data comprises a series of descriptor files each of 
which contain an identification of a user control pro- 
gram to execute, a transition condition that indicates 
when the execution of that user control program is to 
terminate, and which descriptor file is to be processed 
next as well as the program processors to process it. A 
mechanism is also provided to enable the program pro- 
cessors to execute other programs In as background 
tasks without adversely affecting the execution of the 
control programs. 
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PROGRAMMABLE CONTROLLER WITH 
MULTIPLE TASK PROCESSORS 

The field of the invention is programmable control- 5 
lers such as those described in U.S. Pat Nos. 3,810,1 18; 
3,942,158; 4,165,534; and 4,442,504. 



BACKGROUND OF THE INVENTION 



10 



Programmable controllers are typically connected to 
industrial equipment such as assembly lines and machine 
tools to sequentially operate the equipment in accor- 
dance with a stored program. In programmable control- 
lers such as those disclosed in the above cited patents, 
for example, the control program is stored in a memory 15 
and includes instructions which are read out in rapid 
srvpimrr and executed to *ramin*> the condition of 
selected sensing devices on the controlled equipment, 
or to energize or de-energize selected operating devices 
on the controlled equipment contingent upon the status 20 
of one or more of die examined sensing devices. 

The processor for these controllers is designed to 
rapidly execute programmable controller type instruc- 
tions which in medium to large sized controllers in- 
cludes not only instructions that manipulated single-bit 25 
input and output data, but also arithmetic instructions, 
file handling instructions, timers and counters, sequenc- 
ers and other, more complex instructions. Such instruc- 
tions have become quite standardized in the industry 
and they may be directly associated with elements of a 30 
ladder diagram which is easily understood by control 
engineers. Program panels such as those disclosed in 
U.S. Pat, Nos. 3,798,612 and 3,813,649 and in U.S. Pat. 
No. 4,070,702 have been developed to assist the user in 
developing and editing ladder diagram type control 35 
programs comprised of such programmable controller 
instructions. 

To insure that the programmable controller can re- 
spond quickly to change in the status of sensing devices 
on the controlled system, h is imperative that the con- 40 
trofler execute the control program repeatedly at a very 
high rate. The rate at which a programmable controller 
can execute the instructions in its instruction set, as well 
as the size of the control program, are the primary 
factors which determine the rate at which the program- 45 
mable controller can repeatedly execute, or "scan", the 
control program. 

While ladder diagram control programs are particu- 
larly easy to create and edit for relatively small to me- 
dium scale control tasks, they become cumbersome and 50 
inefficient to use in large control tasks. Large ladder 
diagram control programs are difficult to understand, 
difficult to trouble shoot, and require a long time to 
execute. 

U.S. patent application Ser. No. 06/717,221, filed on 55 
Mar. 28, 1985 entitled "Programmable Controller with 
Function Chart Interpreter" addresses this problem. 
The controller described therein includes a processor 
which stores a plurality of separate ladder control pro- 
grams that are logically related to each other by a 
stored function chart program, and the processor is 
operable to execute the stored function chart program 
which directs which ones of the stored ladder programs 
are to be repeatedly executed by the processor at any 
point in time. It has been discovered that large control 65 
tasks can usually be broken down into separate control 
steps which are executed in a sequential order as the 
controlled machine or process advances through its 



60 



states. Each control step is defined by a separately exe- 
cutable ladder program which is easy to understand and 
which may be executed at a very high scan rate. The 
sequence in which the separate control steps are exe- 
cuted is defined by the function chart program which is 
a general expression of how the controlled machine or 
process is to operate. The user may thus define the 
general manner in which the machine or process is to 
operate using function chart constructs, and then define 
the detailed operation of the machine or process in 
separate, easily managed ladder programs. 

The previous applications of function chart and lad- 
der programs have been in programmable controllers 
having a single processor for executing the programs. 
Recently a programmable controller has been con- 
ceived which employs several processors each capable 
of simultaneously executing a separate ladder program. 
This type of controller requires a mechanism for coordi- 
nating the ladder programs being executed by the dif- 
ferent processors. 

Another problem developed when previous pro- 
grammable controllers had to execute complex routines 
such as solving an equation. Such computational tasks 
often tied up the processor for relatively long periods of 
time delaying the execution of other rungs of the ladder 
program. This could result in certain portions of the 
controlled equipment not being supervised frequently 
enough by the programmable controller. 

SUMMARY OF THE INVENTION 

A programmable controller executes, a single ma- 
chine operation program enabling a machine to carry 
out a plurality of programmed functions. Each step of 
the machine operation program is defined as a separate 
user control program. The programmable controller 
includes a plurality of individual processor modules 
each of which is capable of simultaneously executing a 
user defined control program. A storage means is pro- 
vided to store the control programs and data indicating 
the sequence in which the control programs are to be 
executed. The programmable controller also includes 
one or more input/output (I/O) modules for interfacing 
it to sensors and actuators on the controlled machine. 
These I/O modules may interface the controller to the 
sensors and actuators directly or indirectly through 
remote I/O adapters. 

Typically, the operation of the controller is defined 
by a user provided function chart and a series of control 
programs, such as ladder programs. The function chart 
sets out the overall process to be performed in a se- 
quence of steps. The function chart is broken down into 
a series of descriptors each of which contains data speci- 
fying a processing step to be performed, a transition 
condition that occurs when the step is completed, and a 
pointer to the next descriptor in the series. The descrip- 
tors of the function chart guide the overall flow of 
program execution. The programmable controller in- 
cludes means for interpreting the descriptors to control 
the execution of the control programs by the plurality 
of processors. 

Each processing step is assigned to one of the proces- 
sor modules for execution. The step is further defined 
by a process control program which is either a conven- 
tional ladder diagram program or a high level language 
program. In the preferred embodiment, the control 
program is compiled and stored in a local memory of 
the respective processor module that has been assigned 
to execute the program. Once a processor module be- 
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gins executing a specific control program, it repeatedly 
carries out the execution until the associated transition 
condition occurs. At that time the next descriptor 
pointer is read for information as to the next step to 
perform. 5 

The programmable controller further includes a 
mechanism for allotting a portion of the program execu- 
tion time of each processor module for the execution of 
programs other than control programs. This allows 
complex time consuming tasks to be executed in a time 10 
slice manner without adversely interfering with the 
execution of the control programs. 

In an embodiment of the present invention, each of 
the processor modules has an external interrupt which 
enables an external device to be coupled directly to the 15 
processor module. This external device is able to inter- 
rupt the regular program execution by the processor 
module and cause an interrupt routine to be executed. 
. A general object of the present invention is to pro- 
vide a programmable controller which employs several 20 
processors to control the operation of a machine. 

An object of the present invention is to provide a 
programmable controller wherein portions of a single 
machine operation program are executed simulta- 
neously on several parallel processors. 25 

Another object is to incorporate a mechanism in the 
programmable controller which directs the processor's 
execution of a plurality of control programs. 

A further object of the present invention is to periodi- 
cally execute other time consuming programs by the 30 
processor means without such execution having a sub- 
stantial adverse affect on the execution of control pro- 
grams. 
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In the drawings which illustrate the embodiments of 
the present invention: 

FIG. 1 is a perspective view of a programmable con- 
troller which employs the present invention; 

FIG. 2 is a schematic block diagram of the program- 40 
mable controller system shown in FIG. 1; 

FIG. 3 is a schematic block diagram of the System 
Controller for the programmable controller of FIG. 2; 

FIG. 4 is a schematic block diagram of a Program 
Execution Processor of the programmable controller 45 
shown in FIG. 2; 

FIG. 5 is a schematic block diagram of the random 
access memory of the Program Execution Processor of 
FIG. 4; 

FIG. 6 is a schematic block diagram of the remote 50 
input/output scanner of the FIG. 2 programmable con- 
troller; 

FIG. 7 is a diagram of the System Controller memory 
data structure; 

FIG. 8 is a diagram of the I/O Scanner memory data 55 
structure; 

FIG. 9 is a diagram of the Program Execution Pro- 
cessor memory data structure; 

FIG. 10 is an exemplary function chart diagram; 

FIGS. 11 A, B and C are illustrations of the descrip- 60 
tor file data structures generated from the function 
chart program of FIG. 10; 

FIGS. 12 A and B show the entries in the mailboxes 
of FIG. 14 for different types of messages; 

FIG. 13 is a flow chart of the programmable control- 65 
Ier initialization routine; 

FIG. 14 is a schematic representation of a portion of 
the system of FIG. 1 used to described the communica- 



tion of messages between modules of the programmable 
controller; 

FIG. 15 depicts a flow chart of the program steps to 
initiate the sending of a message from one module to 
another in the programmable controller; and 

FIGS. 16, 17, 18 and 19 are flow charts of portions of 
the software for interpreting function chart data and 
executing user control programs. 

DETAILED DESCRIPTION OF THE 
INVENTION 

With initial reference to FIG. 1, a programmable 
controller 10 of the present invention is housed in a rack 
12 which includes a series of slots that receive a plural- 
ity of printed circuit board modules. These functional 
modules connect to a mother board which extends 
along the back surface of the rack 12 to provide a back- 
plane 11. The backplane 11 has a plurality of module 
connectors which are interconnected by a conductive 
pattern on the backplane. The backplane 11 provides a 
series of signal buses to which the modules connect 
The rack 12 contains a power supply module 14, a sys- 
tem controller 16, a number of program execution pro- 
cessor modules 18 and a plurality of remote input/out- 
put (I/O) scanner modules 20, although only one scan- 
ner module is required. The remaining locations in rack 
12 are empty and the slots are covered by blank plates 
until additional functional modules are to be inserted in 
these slots. The physical construction of the rack 12 is 
disclosed in U.S. patent application Ser. No. 06/909,710 
filed on Sept 22, 1986, and assigned tb the same as- 
signee as the present invention. 

Up to four remote I/O scanner modules 20 interface 
the controller 10 to external remote I/O racks 17 via 
serial I/O data links, such as link 15. Each remote I/O 
rack 17 has a plurality of local I/O modules 19 which 
are coupled to individual sensors and actuators on the 
controlled equipment The local I/O modules 19 may 
take many forms and may include, for example, D.C. 
inputs or outputs, A.C inputs or outputs, analog inputs 
or outputs, and open or closed loop positioning mod- 
ules. The I/O racks 17 and networks 15 employ conven- 
tional interface and communication technology. The 
remote I/O rack 17 also contains an adapter module 19'; 
such as the one described in U.S. Pat No. 4,413,319, 
which controls the transmission of data via the I/O 
network 15 between the I/O modules 19 and the scan- 
ner modules 20. 

The system controller 16 is connected through cable 
25 to a programming terminal 24, which is used to load 
the user programs into the programmable controller 
and configure its operation, as well as monitor its per- 
formance. The terminal 24 is a personal computer pro- 
grammed to enable the user to develop the control 
programs on the terminal, which programs are then 
downloaded into the programmable controller. Once 
the programs have been loaded into the programmable 
controller 10 and its operation debugged, the terminal 
24 may be disconnected from the system controller 16 if 
further monitoring is not required. The system control- 
ler 16 may be also connected via a cable 26 to a local 
area network 28 over which it may receive data and 
programming instructions, as well as issue status infor- 
mation and report data to a host computer. This enables 
a central host computer or central terminal to program 
and control the operation of a plurality of programma- 
ble controllers on a factory floor. 
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Different steps of a function chart program are as- 
signed to various ones of the program execution mod- 
ules 1ft. The user control program for each step is stored 
in the local memory of the corresponding program 
execution module 18, For example the user control 
program may be a conventional ladder program. Sev- 
eral user control programs may be executed simulta- 
neously on different ones of the program execution 
modules. At other times a ''background task** may be 
executed on one program execution module 18 while 
another module 18 executes a user control program. 

During the course of carrying out a user control 
program, the pr ogr am execution module 18 reads input 
status date from the input image tables in one or more of 
the I/O scanner modules 20. As called for by the pro- 
gram mstructions, the program execution module also 
writes output state data to the output image table in the 
I/O scanning module 20 that services the respective 
output device. Access to the I/O tables is obtained via 
the rack backplane 11. 

When a program execution module completes a func- 
tion chart step, it sends a command to the program 
execution module 18 containing die next step to be 
executed. The command identifies the next step and 



tern housekeeping functions, such as providing an indi- 
cation of the system status and supervising access to the 
backplane 11. 
During normal operation of the programmable con- 
5 troller, the system controller takes care of communica- 
tion with the external devices that are connected to it, 
such as network 28 and programming terminal 24. The 
most significant task is communicating with the termi- 
nal 24 to provide information allowing the operator to 
10 monitor the system performance and to detect faulty 
sensors or actuators. Another task supervised by the 
system controller is the exchange of data with a host 
computer or a peer programmable controller via the 
local area network 28. Tins enables the host computer 
15 to collect statistics from one or a number of program- 
mable controllers regarding their operation. In addition 
to these functions another function the system control- 
ler 16 receives all programming changes and sees to it 
that the program in the corresponding program execu- 
20 tion module 18 is updated. For example, this includes 
adding, deleting and changing various rungs of the 
ladder program. 

The system controller as shown schematically in 
FIG. 3 connects to the backplane buses 21-23 and is 
instructs th** program execution module 18 to begin 25 divided into three sections (delineated by dashed lines) 
executing it for backplane interface, processing and communication 

operations. The backplane interface section supervises 
Hardware the backplane access for all the rack modules and inter- 

In order for the data and commands to be transfered faces the controller module 16 to the backplane 11. The 
among the modules of the programmable controller, the 30 processor section executes a supervisory program for 
modules are interconnected as shown in FIG. 2. the controller 10. The communication section is primar- 

of the blocks in FIG. 2 contains a reference to ily responsible for communicating with external termi- 
other Figures of the drawings that contain the details of nal 24 and local area networks, such as LAN 28. Bach 
the component represented by the block. Each of the of the processor and communication sections includes a 
modules is connected to the rack backplane 11 which 35 set of internal buses, communication buses 31-33 and 
consists of separate control, data and address buses, processor buses 61-63 respectively. 
21-23 r e sp ec tiv ely. The control bus 21 consists of a Various circuits connected to the communication 
number of separate lines to which a module may con- buses control the interfacing of the system controller 16 
nect to depending upon the control signals required for to the programming terminal 24 and the local area net- 
that type of module. The data bus 22 is thirty-two bits 40 work 28. The communication buses consist of control 
wide and the address bus is 27 bits wide. bus 31 having a number of individual control lines run- 

in the preferred embodiment, each of the system ning between various components in the communica- 
controller 16, program execution processor modules 18 tion section, an eight bit wide data bus 32 and a sixteen 
^t»h remote I/O scaimc modules 20 includes a remov- bit wide address bus 33. The communication section is 
able daughter board containing a local memory for data 45 built around a microprocessor 30, such as the model 
and operating instructions for that module. The daugb- Z80 manufactured by Zflog, Incorporated. The micro- 
ter board contains a battery to sustain the memory when processor 30 executes machine language instructions 
power is removed from the controller. The memory 134 which are stored in a read-only memory (ROM) 34. The 
in ffr^f 1 remote I/O scanner module contains an I/O instructions are fetched from the ROM, decoded and 
image table that indicates the state of each of the sensor 50 then executed by the microprocessor 30 to carry out the 
devices and the desired state of each of the controlled communication functions. The program controlling 
actuators connected to the scanner module 20. The these functions is similar to that employed in previous 
system controller's memory 69 contains various seg- programmable controllers. 

ments that store data regarding die system status and A conventional address decoding circuit 36 receives 
configuration as well as information relating to specific 55 each address issued by the microprocessor 30 and de- 
system operations. Each of the processor modules 18 codes it to produce the proper set of signals on control 
have a random access memory 106 which stores the lines 31. For example, if the microprocessor 30 is access- 
function chart data, user control programs and their ing the ROM 34, the add r ess decode circuit 36 will 
operating variables. recognize that the address sent by the microprocessor 

Each of the functional modules of the programmable 60 30 on bus 33 is within the range of addresses at which 



controller 10 will be described in detail in the following 
sections. 

System Controller 

As noted previously, the system controller module 16 65 
provides a communication interface for the program- 
mable controller to external terminals and local area 
networks. The system controller 16 also performs sys- 



the ROM is located. Once it has recognized which 
device in the communications section is to be accessed, 
the address decode circuit 36 produces control signals 
for the device to carry out the access. 

Two serial input/output devices, UART 46 and serial 
input/output controller (SIO) 48, are also connected to 
the three communication buses 31-33. The UART 46 
may be any of several commercially available universal 
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asynchronous receiver/transmitter integrated circuits. 
The UART 46 converts the parallel data which is pres- 
ent on the communication data bus 32 Into a properly 
formatted serial signal which is fed to an input/output 
line driver/receiver 50. The line driver 50 provides 5 
output signals corresponding to any one of several serial 
signal standards, such as RS232, RS423 or RS422. The 
serial I/O communication controller 48 may be any of 
several commercially available integrated circuits 
which service two synchronous serial communication 10 
channels. The SIO 48 interfaces the communication 
section of the system controller 16 to local area net- 
works connected to the line drivers 52 and 54, such as 
network 28 of FIG. 1. The programming terminal 24> 
shown in FIG. 1, is connected to one of these line driver 15 
52 or 54. 

Also located within the communication section is a 
random access memory (RAM) 38 for temporary stor- 
age of data received from or to be sent to the various 
external devices connected to the system controller. 20 
The RAM 38 may be accessed via address bus 33 so that 
data may be written into or read from the memory via 
bus 32 depending upon enabling signals from control 
bus 31. RAM 38 incorporates a parity circuit which 
analyzes each digital byte being stored in the RAM and 25 
produces a parity bit using conventional techniques. 
This parity bit is employed to check the integrity of the 
data read from the random access memory 38. A direct 
memory access (DMA) circuit 42 is provided to enable 
rapid data exchange between the SIO 48 and the RAM 30 
38 during the communication process. The DMA cir- 
cuit 42 allows the SIO 48 to access RAM 38 to store or 
obtain data which have been received or will be trans- 
mitted over their respective external communication 
channels. 35 

Access to the communication buses 31-33 is con- 
trolled by an arbitration circuit 40 which resolves con- 
flicts when several devices request access to these buses 
at the same time. The arbitration circuit 40 determines 
which component of the communication section will 40 
have access to the shared buses 31-33. A device seeking 
the buses sends a request signal to the arbitration circuit 
40 via a line of the control bus 31 and the arbitration 
circuit grants the request to one device at a time by 
producing an access signal on another control line for 45 
that device. 

A counter/timer circuit (CTC) 44 connects to the 
communication buses 31-33 and to an interrupt terminal 
on microprocessor 30 in order to process interrupt re- 
quests from the other components within the communi- 50 
cations section. The CTC 44 is also configured as a 
tinier to produce an interrupt request to the micro- 
processor 30 at a given periodic interval, such as every 
10 milliseconds, so that various routines may be periodi- 
cally executed regardless of the task then being per- 55 
formed by microprocessor 30. In response to an inter- 
rupt request from the CTC 44, the microprocessor 30 
reads a vector from the CTC 44 directing the micro- 
processor to-the appropriate interrupt service routine 
stored in ROM 34, such as performing a data I/O re- 60 
quest from either UART 46 or SIO 48. 

Referring still to FIG. 3, the processor section is 
linked together by a set of buses that comprise control 
lines 61, a sixteen bit data bus 62 and a twenty-three bit 
address bus 63. Access to these buses is controlled by an 65 
arbitration circuit 64 similar to circuit 40 on the commu- 
nication buses. Two sets of data gates 56 and 58 extend 
between the communciation buses 32 and 33 and: pro- 
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cessor buses 62 and 63 of the system controller module 
16. Specifically, the first set of gates 56 provides an 
eight bit bidirectional connection of the communication 
section data bus 32 to the data bus 62 of the processor 
section; and the second set of gates 58 connects the two 
address buses 33 and 63. The data gate 56 consists of 
two sets of eight individual tristate data gates, each set 
controlling data flow in one direction between the two 
buses 32 and 62. Only the lower eight lines of the pro- 
cessor data bus 62 are coupled to the eight bit communi- 
cation section data bus 32. As addressing will only 
occur from the processor section to the communication 
section, address gates 58 consist of one set of sixteen 
tri-state signal gates coupling the sixteen communica- 
tion address bus lines 33 to the lower sixteen address 
lines in the processor section. An interbus control cir- 
cuit 60 is connected to control lines 61 and 31 from the 
processor and the communication sections, respec- 
tively, and in response to access request signals from 
arbitration circuits 40 and 64, the control circuit 60 
enables the data and address buffers 56 and 58. 

The processor section is built around a sixteen-bit 
microprocessor 66, such as a model 68010 manufactured 
by Motorola Inc., which executes program code stored 
in read only memory 68. The 68010 microprocessor is 
essentially a memory mapped device and does not have 
any input/output lines directly connected to it. There- 
fore, its access to other components on the processor 
bus must be accomplished through issuing addresses on 
bus 63. The address sent from the microprocessor 66 is 
decoded in an address decode circuit 70 to produce the 
proper control signals for the accessed component. The 
processor address decoder 70 functions in much the 
same manner as the communication section address 
decoder circuit 36. The processor section also contains 
an interrupt processor 72 which controls interrupts to 
the microprocessor 66 and provides the proper instruc- 
tion address vectors. 

A data transfer acknowledge and bus error 
(DTACK/BERR) circuit 74 is also connected to the 
processor control bus 61. Circuit 74 responds to signals 
from the various components in the processor section to 
acknowledge the completion of a data transfer and issue 
bus error signals in the event of improper addressing or 
failure of data transfer. These signals are acted on by the 
rnicroprocessor 66 which takes corrective action. The 
processor section also includes clock circuit 89 that 
contains the main system clock and a real time clock. A 
system status circuit 88 receives input signals related to 
the status of the entire system 10 and provides an indica- 
tion of that status. 

The main random access memory (RAM) 69 for the 
system controller 16 is also connected to the processor 
buses 61-63. The RAM 69 is a static memory containing 
393,216 (384K) memory locations each of which is 16 
bits wide and serves as the system memory for the entire 
controller 10. The system memory 69 can be directly 
accessed via the backplane 11 by other modules in the 
system without the intervention of the central process- 
ing unit 66 within the system controller. 

FIG. 7 illustrates the data structures within the main 
system memory 69 included in the system controller 
module 16. The system memory 69 stores separate data 
files, which contain data for performing specific func- 
tions during the operation of the programmable control- 
ler. The data structures include various forms of data 
such as integers, floating point numbers, ASCII charac- 
ters and various control structures. The first file 200 is a 
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directory of the other files stored in the system control- Communication parameters are also stored in this 
ler memory 69. The remaining memory is divided into a section 203 for configuring the UART 46 and the serial 
system status file 201, system data table 202 and a set of I/O module 48 within the communication section of the 
system support files 203. system controller 16. Among other things these parame- 
The system status file 201 contains data relating to the 5 ters include baud rate, word size and control bits for the 
configuration of the entire programmable controller 10. serial data signal format For example, parameters for 
Included in this file is information identifying the van- communicating with the operator terminal 24 are stored 
ous user selectable features of the programmable con- in this portion of the system memory. In addition, as 
trailer that have been enabled by the system operator. noted previously, a number of programmable control- 
The real time clock data regarding the time of day, 10 lers may be connected via the local area network 28, in 
month, day and year are also included in this portion of which case, parameters must be provided in each Con- 
ine system memory. Digital words indicating the occur- trailer instructing them how to communicate over the 
rence and type of various system faults and errors, as network. 

well as pointers indicating the program instruction Referring again to FIG. 3, the processor section of 
being executed when the fault occurs are stored within 15 the system controller 16 interfaces with the backplane 
another sub-file of this section. A section of the system buses of rack 12 via a plurality of components that are 
status file 201 also lists the number and type of all the coupled to both sets of buses. Specifically, the back- 
active modules on the system as well as the relative plane data bus 22 is connected to the processor data bus 
module number and address pointers necessary to ac- 62 by a set of bidirectional data transmission gates 78 
cess each module. For example, if more than one pro- 20 and the backplane address bus 23 is connected to the 
gram processor module 18 or remote I/O scanner mod- processor address bus 63 by another set of bidirectional 
ule 20 is present in rack 12, the user must assign a unique gates 76. When the system controller 16 seeks to exer- 
number via a thumb wheel on the module to distinguish cise control over the backplane 11 of the programmable 
the various modules of that type. The thumb wheel controller 10, a master mode control circuit 81 responds 
setting is read by the system controller during initial 25 to signals on the control lines of the processor bus 61 
start-up of the system and stored in this portion of the and issues the proper control signals over the backplane 
system status file 201. control bus 21 to access other modules within the rack 

The system data table 202 contains data that is shared 12. 

by more than one module. For example, results of vari- When another module within the rack 12 seeks access 

ous computations from one program processor module 30 to the system controller 16, in order to read the contents 

18 may be stored in this portion of the system memory of main RAM 69, for example, the system controller 

so that other program processor modules may readily becomes subordinate to the control of the backplane 11 

access the data. Memory space is allocated within the by this other module. In this circumstance, a slave mode 

system data table 202 to store the data that was received control circuit 82 within the system controller 16 re- 

or that win be tra n sm itt ed via the various external com- 35 sponds to the address of the system controller that ap- 

munication links of the system controller's communica- pears on the backplane address bus 23 and to control 

tkm section. Other modules in the system 10 are directly signals on the control lines of the backplane bus 21 

able to access these storage locations. which lead from the other module. In response the slave 

The system data table 202 also contains the value of mode control 82 issues signals to transmission gates 76 

various system counters and variables which are either 40 and 78 enabling the other backplane module to access 

used by the system controller 16 or which are com- the system controller 16. In this latter instance, the 

monly used by a number of other modules such as pro- master mode control circuit 81 is in a dormant state, 

gram processor modules 18 or the I/O scanner modules The two bus gates 76 and 78 receive enabling control 

20. The final sub-file within the system data table 201 is signals from the master or slave mode control circuits 

a space allocated for the user defined data for various 45 81 and 82 via the lines of control bus 61 depending upon 

programs that the user has loaded into the programma- the mode of backplane communication. A backplane 

ble controller. arbitration circuit 84 supervises access to the backplane 

The final section 203 of the system controller main and resolves conflicting requests for access from the 

memory 69 is dedicated to the system support files. modules in the system. 

These files include the source program information for 50 As noted above the system controller module 16 

the function chart program. The programmable con- executes programs which control the initialization of 

trailer 10 does not directly execute the function chart the system and communication with external comput- 

program. However, as will be described later, the func- ers. It does not execute the user control programs, 
tion chart is employed during the programming step to 

generate data which is used to direct the operation of 55 Program Execution Processor 

the program execution modules 18. In order to permit The program execution processor modules 18 store 

the subsequent editing of these programs, a source ver- and execute specific user control programs, such as 

sion of the function chart must be available for display ladder programs. One of these modules is shown sche- 

on the programming terminal. As also will be described matically in FIG. 4. During this execution the modules 

hereinafter, the support files 203 contain simultaneous 60 18 read the state of the sensing devices from input image 

counters for execution of various branches of the func- table in the memory 134 of the various I/O scanner 

tion chart Although the local memory in each module modules 20, and write output data from its memory to 

contains data regarding its status, in some instances the output image tables in the I/O scanner modules, 

these memories do not have a battery to sustain them. In Data is also obtained from the system memory in the 

order to retain such volatile information after a power 65 system controller 16. 

shut-down, the status information for these modules is In order to perform these tasks, each processor mod- 
replicated in a sub-file of section 203 of the system mem- ule 18 has a set of internal buses 91-93 which are cou- 
ory 69. pled to the backplane 11. Specifically the processor 



module 18 has a thirty-two bit internal data bus 92, a set 
of control lines 91 and a sixteen bit address bus 93* 
These are coupled to the data and address buses of the 
backplane 11 by respective set of tri-state, bidirectional 
transmission gates 94 and 96. The operation of these 5 
gates 94 and 96 is governed by an interbus control cir- 
cuit 95 coupled to backplane control lines 21 and the 
module control lines 91. It should be noted that both the 
internal data bus 92 and the backplane data bus 22 are 
thirty-two bits wide. Therefore, thirty-two bit data 10 
from the processor module 18 can be sent over the 
backplane as one thirty-two bit word if the recipient 
module has a thirty-two bit wide data bus. In some 
processing functions the module 18 operates on sixteen 
bit data, and in such case sixteen-bit words are applied 15 
to the backplane 11. 

The remaining components of the processor module 
18 are connected to the internal buses 91-93. These 
internal buses are driven by a microprocessor 98, which 
is a thirty-two bit niicroprocessor sold commercially by 20 
Motorola, Inc. as the 68020 microprocessor. The micro- 
processor 98 has an interrupt port which is coupled to 
an interrupt interface circuit 99. This interface circuit 
receives signals from four external interrupt lines con- 
nected to terminals on the front of the processor module 25 
18. These external interrupt lines permit devices which 
sense high priority events, to be interfaced directly to 
the processor module for fast response. Three other 
interrupt lines on the interface circuit 99 connect to 
circuits within the processor module 18. A signal on any 30 
of these external or internal interrupt lines causes the 
microprocessor 98 to immediately interrupt normal 
program execution and execute a routine that corre- 
sponds to that interrupt line. The user may program the 
routines for the external interrupts, but the internal 35 
interrupts are serviced by dedicated interrupt service 
routines. 

The processing capability of the processor module 18 
is also supported by a floating point co-processor 100, 
and by a bit co-processor 102. The floating point co- 40 
processor 100 is commercially available from Motorola, 
Inc. as the 6881, and it is specifically designed to work 
with the 68020 microprocessor 98. The bit co-processor 
102 is a custom integrated circuit for carrying out Bool- 
ean logic operations on individual bits of the data 45 
words. Bit co-processors have been used in programma- 
ble controllers in the past to execute a set of ladder 
diagram instructions using hardwired logic as described 
in co-pending U.S. patent application Ser. No. 717,221 
filed on Mar. 28, 1985 and entitled **Programmable 50 
Controller with Function Chart Interpreter". 

The three processors 98, 100 and 102 operate in tan- 
dem to execute specific types of instructions included in 
the control program. The microprocessor 98 may begin 
execution of the control program and when it encoun- 55 
ters a floating point arithmetic function, the floating 
point co-processor 100 is enabled and the CPU 98 relin- 
quishes the internal buses 91-93 to it The floating point 
co-processor 100 takes over the processing function 
until the arithmetic operation is complete at which time 60 
the microprocessor 98 resumes program execution. If 
the control program calls for bit processing (Le. con- 
tains an instruction in the set for the bit co-processor 
102), the microprocessor immediately relinquishes con- 
trol to the bit co-processor 102 by writing the address of 65 
the control program instruction into a program counter 
in the bit co-processor 102. The bit coprocessor 102 
then removes the microprocessor 98 from the internal 
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buses 91-93 and executes the subsequent control pro- 
gram instructions until a stop instruction is encountered. 
At this point the bit co-processor 102 signals the micro- 
processor 98 via the control bus 91 to resume control of 
the buses and execution of the control program. Ap- 
proximately 85-90 percent of a typical control program 
of the "ladder 9 * type may be executed by the bit co- 
processor 102. The operation of the custom Boolean 
logic bit co-processor 102 in conjunction with a micro- 
processor is fully described in above-cited copending 
U.S. patent application Ser. No. 717,221. 

The processor module 18 includes a data size ac- 
knowledge (DASACK) circuit 108. This circuit pro- 
vides a two-bit code on two of the control bus lines 
which indicates the "width" of the data on the data bus 
92. As will be described in more detail below, this data 
may be a long word consisting of thirty-two bits, a 
regular sixteen bit word, or a single eight bit byte. This 
data size information is used by the various module 
components in this data processing. 

The final component of the processor module 18 is a 
control and status circuit 110 which monitors the status 
of the processor module and provides proper control 
signals on various lines of the control bus 91 to enable 
various components in a conventional manner. 

Both a read only memory (ROM) 104 and a read- 
write random access memory (RAM) 106 are con- 
nected to all three internal buses 91-93 within the pro- 
cessor module 18. The ROM 104 contains 16 bit storage 
locations for instructions and constants for the three 
processors 98, 100, and 102. The RAM 106 provides 
storage for the operands and the results of the . various 
computations performed by the processor module 18. 
The control programs to be executed by the module 18 
are also contained in its RAM 106. 

The details of the RAM memory 106 are shown in 
FIG. 5. The random access memory 106 is divided into 
lower and upper banks 112 and 114. Each bank contains 
a number of storage locations, for example 196,608 
(192K) memory addresses. The memory location in 
each bank is sixteen bits wide and both banks can be 
enabled simultaneously to provide storage for thirty- 
two bit data words. As noted above the width of the 
data processed by the execution module 18 may be 
sixteen or thirty-two bits wide. In order to optimize the 
storage capacity when sixteen bit words are processed, 
a transmission gate multiplexer is incorporated into the 
random access memory 106 to allow separate sixteen bit 
words to be stored in both the upper and lower memory 
banks. Specifically, the multiplexer consists of three sets 
of tristate bidirectional transmission gates 116-118, each 
of which provides bidirectional control of sixteen data 
lines. The first set of transmission gates 116 couples the 
sixteen least significant bits (bits 0-15) of the data bus 92 
to the data terminals of the lower memory bank 112. 
Similarly, the third set of transmission gates 118 couples 
the sixteen most significant bits (bits 16-31) of the data 
bus 92 to the data terminals of the upper memory bank 
114. The second set of transmission gates 117 cross 
couples the sixteen least significant bits of the data bus 
to the data terminals of the upper memory bank 114. 
The three sets of transmission gates receive control 
signals from the DASACK 108 via control bus 91 
which enables the various transmission gate sets de- 
pending upon the width and address of the word being 
sent on data bus 92. All of the address bus lines 93 go to 
each memory bank 112 and 114. 
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If thirty-two bits of data are being sent on the data bus 
92, the DASACK 108 enables the first and third sets of 
transmission gates 116 and 118. This stores the sixteen 
least significant bits in the lower memory bank 112 and 
the sixteen most significant bits of the data in the upper 5 
memory bank 114. When a sixteen bit word is being sent 
on the data bus 92 it may be stored in either of the 
memory banks 112 or 114. If it is to be stared in the 
lower memory bank 112, the DASACK 108 enables 
only the first set of transmission gates 116 to pass the 10 
data to that memory bank. To maximize the storage 
capability for sixteen bit words* the separate data may 
also be stored at the same address in the upi per memory 
bank 114* in which case DASACK 108 enables only the 
second set of transmission gates 117 which couples the IS 
sixteen least significant bits of data to the upper memory 
bank. When sixteen bits of data are being processed, the 
third set of transmission gates 118 is never enabled. 

FIG. 9 represents the data structure of the RAM 
memory 106 for each program execution processor 20 
module 18. The memory 106 includes a section 310 
which contains status information regarding the mod- 
ule's operation. Each program execution processor 
module 18 also contains its own data table 312 which is 
stored in the RAM 106. The data table 312 includes 25 
memory locations for various counters, timers and in- 
termediate computation values. 

The largest share of the RAM memory 106 is devoted 
to storing the control programs. The actual program 
contents, as will be described in detail later, comprise 30 
compiled user control programs, independent back- 
ground tasks and various interrupt routines to be pro- 
cessed by the processor modules 18. In order to prop- 
erly carry out the user control programs, support files 
containing the function chart data, called "descriptors," 35 
are also contained within the program area 313. 

In one mode of operation of the program execution 
processor module 18, referred to herein as the "syn- 
chronous mode", the processor module 18 periodically 
copies the entire input image table from the I/O scanner 40 
module 20 into its own memory 106. Space for this copy 
of the I/O image table is provided in memory section 
314. 



Remote I/O Scanner Module 
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As noted above, the I/O scanner modules gather 
input sensor data for use by the program execution 
processor modules 18. Referring to FIG. 1, 2 and 6, a 
remote I/O scanner module 20 couples the programma- 
ble controller 10 to one or more remote input/output 50 
racks 17 containing individual I/O modules 19 which 
interface the sensors, or input devices, and accuators, or 
output devices, to the programmable controller 10. 
Each scanner module 20 periodically requests input 
data pertaining to the status of the input devices con- 55 
nected to the remote I/O racks 17 and stores it in the 
module's input image table for reading by other control- 
ler modules, such as the processor modules 18. The 
scanner module 20 also contains an image table of out- 
put data that it receives from other controller modules, 60 
such as the processor modules 18. At regular intervals 
the updated output data in the scanner module's output 
image table is transferred to the respective remote in- 
put/output racks 17 to control the various actuators 
connected to these racks. 65 

Referring specifically to FIG. 6, each remote I/O 
scanner module 20 connects to the three backplane 
buses 21-23. The I/O scanner 20 contains three sets of 



internal buses: memory access buses 121-123, micro- 
processor buses 131-133 and I/O buses 141-143. The 
three memory buses 121-123 are connected to the back- 
plane 11 by a set of address bus gates 124 and a set of 
data bus gates 126. Both of these transmission gates are 
controlled by an inter-bus control circuit 128 which 
sends signals to the gates 124 and 126 via the memory 
control bus 121. A local random access memory, re- 
ferred to as main RAM 134, is coupled to the three 
memory buses 121-123. It stores the input image table 
for the sensor information being input to the I/O scan- 
ner 20 from the remote I/O racks 17 and it also stores 
the output image table for the output data being output 
to the remote I/O racks 17. 

FIG. 8 shows in detail the data structures stored in 
the main RAM 134 of each I/O scanner module 20. 
These data structures include an I/O image table for the 
remote sensors and actuators serviced by that module 
20. The input image table 210 represents the sensor data 
and consists of three separate sections 212-214. The first 
section 212 is the image of the actual state of the various 
sensing devices. The information relating to the inputs 
that are forced on is contained in the second section 213 
within the input image table 210. As with previous 
programmable controllers, the user may force the status 
of a given sensor to appear to be either on or off regard- 
less of its actual state. This enables the bypassing of 
faulty sensors, for example. Forced on sensors are desig- 
nated by a binary one in an address for each such input. 

The sensors that are forced off are indicated in the 
third section 214 of the input image table 210 by a logi- 
cal zero stored for those sensors. Although by definition 
the user may write into the forced data tables 213 and 
214, the user is prohibited from writing into the actual 
input image table 212. During the operation of the pro- 
grammable controller, the user programs can read ei- 
ther the actual input image data from section 212 or the 
forced image of the sensor. If the forced image is read, 
the scanner module 20 logically OR's the actual sensor 
input state with the forced on data from section 213, 
then that result is ANDed with the forced off data for 
that sensor from section 214. 

The output image table 211, also stored in the main 
RAM 134, includes the output image data table 215 
which represents the status for the output devices con- 
nected to the remote I/O racks 17 serviced by the I/O 
scanner module 20. Typically, this output data is deter- 
mined by the execution of the user control program in 
the processor module 18. A second section 216 repre- 
senting the forced on output data and a third section 217 
representing the forced off output data are also included 
in the output table 211. This allows the user to define a 
given actuator as always being on or off regardless of 
the results from the execution of the user control pro- 
gram. For example, this is useful where a portion of the 
controlled equipment may have to be shut down for 
maintenance and should not be turned on by the user 
control program. The control program may read each 
of the output tables 215-217 individually. If the forcing 
of the output states is disabled the data sent to the re- 
mote I/O racks 17 for activating or deactivating the 
various controlled devices is obtained from the output 
image table 215. If output state forcing is enabled then 
the data sent to the remote I/O racks 17 is a logical 
combination of the three output tables 215-217 using 
Boolean logic that is identical to the combination of the 
three input tables 212-214 described above. 
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Referring still to FIG. 9, the data structure in the 
main RAM 134 of the I/O scanner module 20 also in- 
cludes a block 218 that contains data regarding the 
status of the communication adapter in each of the re- 
mote I/O racks 17 serviced by the module 20* This data 5 
is used during the transfer of information over the I/O 
links 15 with those remote I/O racks. 

Although the state of most of the sensor and operat- 
ing devices may be represented by a single binary bit, 
certain devices, such as position sensors and analog 10 
devices, produce or require information that comprises 
a plurality of digital words. These data may be transmit- 
ted to or from the remote I/O rack 17 into the I/O 
scanner module 20 as a large block of data. Memory 
section 219 in the main RAM 134 contains information 15 
necessary to control such transfers of blocks of data and 
a companion section 220 provides a memory area for 
the storage of the actual blocks of data. For a detailed 
description of this block transfer reference is made to 
U.S. Pat No. 4,413319 entitled "Programmable Con- 20 
troiler for Executing Block Transfer with Remote I/O 
Interface Racks'*. 

Referring again to FIG. 6, the inter-bus control cir- 
cuit 128 also sends control signals to an I/O data arbitra- 
tion circuit 130 which resolves conflicting requests for 25 
access to the memory buses 121-123 from the backplane 
11 and the microprocessor buses 131-133. Two sets of 
transmission gates, address gates 136 and bi-directional 
data gates 138, interconnect the memory buses 121-123 
to the mi croprocessor buses 131-133 and receive con- 30 
trol signals from the I/O data arbitration circuit 130 via 
the memory control bus 121. The operation of the re- 
mote I/O scanner 20 is controlled by an eight-bit micro- 
processor 140 which is connected to three microproces- 
sor buses 131-133. Microprocessor 140 is commercially 35 
available from Zilog, Inc. as the Z80 and it is the only 
device which is directly connected to the microproces- 
sor buses 131-133, other than the sets of transmission 
gates 136, 138, 144 and 146 and the I/O data arbitration 
circuit 130. 40 

A set of address gates 144 interconnects the micro- 
processor address bus 133 to the I/O address bus 143 
and a set of bi-directional gates 146 interconnect the 
data buses 132 and 14Z Both sets of tri-state gates 144 
and 146 receive control signals from the I/O data arbi- 45 
tration circuit 130 via the microprocessor control bus 
131. The microprocessor control bus 131 is directly 
coupled to the I/O control bus 141. 

The I/O control buses 141-143 interconnect the de- 
vices which interface the I/O scanner module 20 to the 50 
remote I/O racks 17. These include a serial I/O inter- 
face circuit 148 which provides two synchronous serial 
input/output channels 150 and 151, each of which has 
its own cable driver/receiver circuit 152 and 153 re- 
spectively. A counter/timer circuit (CTC) 154 and a 55 
direct memory access (DMA) controller 156 are also 
connected to the I/O buses 141-143. The I/O bus sec- 
tion of the scanner 20 also includes a random access 
memory, indicated as I/O RAM 158 for temporary 
storage of input and output data communicated over 60 
I/O serial links 15. A read-only memory (ROM) 160 is 
also connected to the I/O buses 141-143 and it contains 
the programs which are executed by the microproces- 
sor 140 to carry out the functions of the scanner module 
20. An address decode circuit 162 is also connected to 65 
the address and control buses in the I/O section of the 
scanner module 20 to interpret the addresses generated 
by the microprocessor 140 and produce the proper 



enabling and control signals on the lines of control buses 
131 and 141 

The operation of the remote I/O scanner modules 20 
is described in a subsequent section on data acquisition 
and transfer. 

Controller Operation 

The novel architecture of the present programmable 
controller 10 dictates that it functions in a unique man- 
ner. The areas in which the present system operates 
differently than previous programmable controllers 
include system initialization, I/O data acquisition and 
transfer, and intermodule communication. However, 
the most significant difference with respect to this con- 
troller lies in the formulation and execution of the user 
control programs. Each of these unique functions will 
be described in detail 

System Initialization 

During system power-up, the system controller 16 
supervises the configuration of the system and various 
other tasks as shown in the flowchart of FIG. 13. The 
first phase 450 of power-up occurs immediately after 
the system reset signal terminates. During this interval 
no module is allowed on the backplane 11 and the vari- 
ous modules perform local tests of their own memory 
and other subsystems. When each module is finished, it 
releases a common ready line of the backplane control 
bus 21. When the last module has completed its internal 
tests the signal on the ready line is true. This signals the 
system controller 16 to make a transition into the next 
power-up phase. 

During the second phase 451, the system controller 
16 goes on to the backplane 11 and requests the module 
in each slot of the rack 12 to identify itself and provide 
the system controller 16 with various information re- 
garding the module, such as the module type, and ad- 
dresses for various interrupts and data pointers which 
are stored in the system memory 69. Based on the infor- 
mation received from each module, the system control- 
ler 16 verifies that the system is properly configured. 
For example, if there is more than one program execu- 
tion processor module 18 on the system, the system 
controller 16 verifies that each one has a unique module 
thumb wheel designation and that two of them do not 
have the same designation. 

In the next phase 452, the system controller module 
16 stores the backplane communication parameters in 
preassigned memory locations in each module. These 
parameters instruct the modules how to communicate 
over the backplane. Once a module knows how to com- 
municate via the backplane 11 it loads its memory ad- 
dress pointers into memory locations in the system 
memory 69 of the system controller 16. These address 
pointers are used by other modules to access the data in 
the module or issue instruction to it For example each 
module loads the addresses of its interrupts into the 
system status section 201 of the System Memory (FIG. 
7). In the course of this phase, the various functional 
modules may communicate only with the system con- 
troller 16, not with any other type of module. Referring 
again to FIG. 13, the next phase 453 of the initialization 
allows the modules to talk with each other and ex- 
change any necessary data. At the completion of this 
phase, the programmable controller 10 at step 454 
makes a normal transition into the user defined start-up 
mode, typically either '•program" or "run." 
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The system has three primary modes of operation: 
programming, program ran and fault mode, as deter- 
mined by the system controller module 16. Each of 
these modes is subdivided into a number of internal 
modes. For example, the run mode has an initial input 
prescan internal mode which prior to program execu- 
tion causes each of the remote I/O scanner modules 20 
to gather data from their respective I/O racks 17 and 
create an initial input image table 210. Following the 
input prescan,, a program prescan is carried out during 
which one or more of the user control programs are 
scanned once to create an initial output image table 211. 
Once both of these prescan modes have been completed 
and the input and output image tables 210 and 211 have 
been created, the various outputs are enabled and the 
ran mode commences formal execution of the user con- 
trol program. 

In order to explain the formulation and execution of 
the user control program, one must understand how 



processor 140 signals the I/O data arbitration circuit 
130 to disconnect the interconnection of the internal 
buses. 

At other periodic intervals, the remote I/O scanner 
5 module 20 sends output state data to the remote I/O 
racks 17. This process is similar to that described imme- 
diately above with respect to the input status data. The 
microprocessor 140 requests the interconnection of the 
internal module buses 121-123, 131-133 and 141*143. 
10 Once the interconnection is made the output image 
table data in main RAM 134 is transferred to the I/O 
RAM 158. The bus interconnection is then discon- 
nected. The output data in I/O RAM 158 is systemati- 
cally sent to the remote I/O racks 17 over serial links 15 
IS to activate or deactivate the operating devices on the 
controlled equipment 

As noted above, the I/O RAM 158 is used to store the 
data that is sent and received over the serial links 15. 
During the communication process the microprocessor 



data and commands are transferred within the program- 20 140 does not have to access the main I/O image table 

mable controller 10. stored in main RAM 134. This freeing of the main RAM 

. 134 from communication tasks as well as the I/O mod- 
Data Acquisition and Transfer ule's separate internal bus configuration permits other 

Referring to FIGS. 1, 2 and 6, periodically each I/O modules on the backplane 11, such as the system con- 
module 20 gathers input data from sensors connected to 25 trailer 16 and processor modules 18, to directly access 



each of the controller's remote racks 17. This acquisi- 
tion of data is similar to the I/O scans performed by 
previous programmable controllers such as the one 
described in U.S. Fat. No. 4,442,504. While the system 
is in the run mode, each I/O scanner module 20 sequen- 
tially requests each remote rack 17 to send input data 
regarding the status of sensing devices connected to the 



With reference to FIG. 6, the gathering of data from 



the I/O image table data in the main RAM 134. This 
direct access from the backplane does not involve the 
microprocessor 140 which may be simultaneously con- 
trolling the communication with the remote I/O racks 
30 17. 

When the system controller 16 or one of the proces- 
sor modules 18 desires to read the status of a given input 
device, it requests access to the backplane buses 21-23 
in order to interrogate the I/O scanner module 20 that 



the remote I/O racks 17 is carried out by microproces- 35 receives the input data from that particular sensor, 
sor 140 in structin g the I/O data arbitration circuit 130 Upon being granted access to the backplane 11, the 
to enable transmission gates 144 and 146. This couples processor module 18 or system controller 16 addresses 
the microprocessor buses 131-133 to the I/O buses the appropriate I/O scanner module 20. In response to 
141-143. After the connection of the buses is com- this addressing, the interbus access controller 128 
pleted, the microprocessor 140 sequentially sends com- 40 within the respective I/O scanner module 20 receives 
mands to the remote I/O racks via SIO 148 and line an access request signal over a line of the control bus 21 
drivers 152 and 153. In response to these commands the of the backplane 1L The interbus access controller then 
remote racks 17 transmit their sensor input data to the signals the I/O data arbitration circuit 130 that a request 
I/O scanner module 20. The received input data is tern- to access main RAM 134 has been received from an- 
porarily stored in I/O RAM 158. The communication 45 other module. At the appropriate time when the inter- 
protocol used to gather data from the remote I/O racks nal memory buses 121-123 are available to be connected 
17 is similar to mat used by previous programmable to the backplane buses 21-23, the I/O data arbitration 
controllers. circuit 130 signals the interbus access controller 128 that 
At regular intervals the gathered input data is trans- it may connect the backplane and memory buses to- 
ferred from the I/O RAM 158 to the input image table 50 gether via transmission gates 124 and 126. The comple- 
contained within the main RAM 134. This transfer is tion of this connection is then acknowledged by the 
accomplished by the microprocessor 140 requesting inter-bus control circuit 128 to the requesting module 
that the I/O data arbitration circuit 130 couple the via a line of the backplane control bus 21. The other 
memory access buses 121-123, microprocessor buses module then reads from or writes data into the I/O data 
131-133 and I/O buses 141-143 together. If the back- 55 image table in the main RAM 134. The data transmis- 
plane 11 is not coupled to the memory access buses sion may be a single data word or a block of words. The 
121-123, the I/O data arbitration circuit 130 win issue requesting module holds control of the backplane 11 
control signals via control buses 121 and 131 to trans- until all of the requested data has been transmitted to it 
mission gates 136, 138, 144 and 146. In response to the from the I/O scanner 20. When the access is finished the 
control signals, the transmission gates interconnect the 60 inter-bus control circuit 128 is signaled via the back- 
three sets of internal buses. The I/O data arbitration plane control bus 21 and the connection to the back- 
circuit 130 then sends an acknowledge signal to the plane 11 is disconnected. 

microprocessor 140 indicating that the connection has As is seen, die configuration of the I/O scanner mod- 
been made. Upon receiving the acknowledge signal, the ule 20 permits other modules connected to the back- 
microprocessor 140 transfers the data between the I/O 65 plane to have direct access to the I/O scanner's main 
RAM 158 and the main RAM 134. The input data is RAM 134 without the intervention of the scanner's 
stored in the input image table 212 (FIG. 8) of main microprocessor 140. This allows the microprocessor to 
RAM 134. When the transfer is complete the micro- devote its attention to controlling the gathering of sen- 
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sor data and transmitting output commands to the 
equipment actuators. 

The access to the I/O image table data by each pro- 
gram execution processor 18 may be on an "as needed" 
basis or periodically an image of the entire I/O data 5 
table may be read by the processors from the scanner 
modules 20. In the "as needed" mode whenever the user 
controller program being executed by the processor 
module 18 requires the evaluation of a sensor status, the 
processor module 18 gains access to the backplane buses 10 
21-23 and requests data from that sensor via the appro- 
priate I/O scanner 20. This mode is referred to as "asyn- 
chronous" in that the access to the I/O scanner module 
20 is on an "as needed" basis and not a periodic basis 
which is synchronized to the execution of the user pro- 15 
gram. 

An alternative method of accessing the sensor input 
data from the I/O scanner modules 20 is in a synchro- 
nous, or periodic, fashion. At a given point within the 
execution of the user control program by the program 20 
execution processor 18, the input image table 210 from 
each I/O scanner 20 is read and copied into the local 
memory 106 within the processor module 18. For exam- 
ple, just prior to the commencement of each pass 
through the user control program, the processor mod- 23 
ule 18 gains access to the backplane 11 and interrogates 
each of the I/O scanner modules 20 copying each scan- 
ner's input image table 210 into the processor module 
memory 106. This ensures that the input data being used 
during the subsequent pass through the user program 30 
will remain constant and that each rung will be evalu- 
ated using the same sensor status. The choice of which 
mode of operation to use is left to the operator/pro- 
grammer and depends upon the characteristics of the 
particular function chart and user control programs 35 
being executed. Unless otherwise specified by the oper- 
ator, the system defaults into the asynchronous mode. 

Referring particularly to FIGS. 2 and 8, the output 
image table 211 in each I/O scanner module 20 is up- 
dated immediately upon a change of the status of an 40 
actuator connected to one of the remote I/O racks for 
that module. Specifically, when the user's program calls 
for a change in status of a controlled actuator, the pro- 
gram execution processor 18 gains access to the I/O 
scanner module 20, as described above, and reads from 45 
the I/O scanner RAM 134 the output image table word 
that contains the bit or bits to be changed. Once the 
processor module 18 receives a copy of that output 
image table word, it changes the corresponding portion 
and writes the altered word back into the output image 50 
table 211 of the same scanner module 20. During this 
reading and writing of the I/O scanner module's RAM 
134, the program execution processor module 18 retains 
control of the backplane buses 21-23 so that no other 
module may read or alter the output image table 211 of 55 
that scanner module 20 while the processor module 18 
is performing its output function. This ensures that the 
output image table 211 is not changed or that another 
execution module uses stale data. It is, however, up to 
the user, through the control programs, to ensure that a 60 
given controlled device is only being activated or deac- 
tivated by one processor module 18 at a time. 

Once a module has relinquished its control of the 
backplane 11 another module in the system may access 
the backplane. If more than one module seeks such 65 
access at the same time, the backplane arbitration circuit 
84 in the system controller 16 resolves the conflict The 
arbitration circuit 84 implements the rotating priority 



scheme described above whereby the highest priority 
level for backplane access passes from one module to 
the next in rack slot number order. Initially, the module 
in the leftmost rack slot has the highest priority and the 
priority level decreases with each slot to the right At 
this time, if a conflict exists between the modules in the 
second, fourth and sixth slots, the module in the second 
slot gains access. When a module is granted access, the 
priority levels shift one module slot to the right Now 
the second module has the highest priority and the 
module in the first slot has the lowest priority. Then, if 
the modules in the first, third and eighth slots simulta- 
neously seek access to the backplane 11, the third mod- 
ule gets access as it has the highest priority among the 
three. Then the eighth module has access and finally the 
first module is granted access the backplane 11. The 
priority keeps shifting whenever any one of the modules 
accesses the backplane 11. After the module in the last 
slot has had the highest priority level, the highest level 
rotates back to the module in the first, or leftmost, slot 

The system controller memory 69 may also be di- 
rectly addressed by other modules on the backplane 11 
so that they may gain access to system data. During the 
execution of the user control program, the main func- 
tions performed by the system controller 16 relate to the 
handling and execution of communications on the local 
area network 28 and the programming terminal 24. 

A module requiring data from the system controller 
module 16 or an I/O scanner module 20 is able to access 
the main RAM's in these modules directly via the back- 
plane 11. However, when a module desires to send a 
block of data or a command to another module in the 
rack 12, a different technique for communication be- 
tween the two modules must be employed. 

Inter-module Communication 

As indicated above, I/O data may be transferred 
directly from one module on the backplane 11 to an- 
other module. This direct transfer is possible when data 
is being read from or written to very specific memory 
data structures, such as an I/O image table, in the other 
module. However, in the present multiprocessor sys- 
tem, other forms of messages which do not reside in 
predefined data structures are often conveyed between 
the modules. A more general purpose inter-module 
communication protocol is required for such messages. 
This process is referred to herein as sending "maiP\ 

Within each module that is capable of receiving mail 
is a set of mailboxes as illustrated in FIG. 14. The set 
comprises sections for "priority" and "regular" mail. 
Each section has sixteen mailboxes, each consisting of a 
two word storage location. These sixteen mailboxes 
allow the exchange of messages with modules in the 
eight slots of the main programmable controller rack 12 
and with eight modules in an auxiliary rack (not 
shown). Each of the mailboxes in each section corre- 
sponds to one of the slots in the two racks. During the 
configuration process, each module writes the address 
of the top of its mailbox set into the area of the system 
status file 201 (FIG. 7) which contains data for that 
module. The address of each module's mailbox inter- 
rupt is also stored in the system status portion 201 of the 
main system memory 69. 

A "priority mail" message forms an urgent command 
which the recipient module is to immediately carry out 
The command is either executed within the mail han- 
dling task which detects the receipt of the command, or 
it is passed to a destination task for processing. The 
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priority mail message consists of two sixteen bit words 
as shown in FIG. 12A. The first bit of the first word is 
a zero designating the message as priority mail. The 
next seven bit field (CMD) of the first word contains the 
coded form of the command to be executed which is 
selected from the following list: 



Command 
Code 



Command Description 



1H 


Mailbox Command Acknowledgment 


2H 


Begin Function Chart Step Execution 


3H 


Drain Interrupt Routine Execution 


;4H 


Change System Mode 


5H 


Change Power Up Fhaae 


6H 


End Power Up 


7H 


Hah Active System Operation 



10 



15 



20 



25 



30 



35 



The remaining bits of the first word are not used by 
every command. The second word contains a pointer to 
a location within the recipient module local memory 
containing data for executing the command. For exam- 
ple, a priority mail message is sent by one program 
execution processor module 18 to inform another such 
module to commence the execution of a specific user 
program for a given function chart step. In this instance 
the command (CMD) in the first word is **2H M telling 
the recipient module to begin a new function chart step. 
The second word is an offset pointer for the table con- 
taining the address in the recipient's memory that con- 
tains information about the step and hs control pro- 
gram. This information is passed to the function chart 
interpreter program in the recipient module. 

Referring to FIGS. 12A and 14, in order to send mail 
the source module 230 first formulates the two word 
message in its memory. The transfer of the message is 
controlled by a mail handling task in the module, see 
also the flowchart of FIG. 15. The priority mail transfer 
process is initiated by the source module 230 accessing 
the system controller main RAM 69 via the backplane ^ 
11 to obtain the addresses of the mail interrupt and the 
top of the set of mailboxes 233 in the recipient module 
232 at step 460. These addresses are stored in the system 
status section 201 of the system controller's main RAM 
69 (FIG. 7). The source module 230 knows the index 45 
from the top of the mailbox set 233 in order to access its 
mailbox slot in the recipient module. The mail handling 
task in the source module 230 then again seeks access to 
the backplane 11 at step 461. When it receives access to 
the backplane 11 at step 462, the source module 230 
checks the first word of its priority mailbox in the recip- 
ient module memory 234 at step 463. If the first word of 
the mailbox is non-zero indicating a previous message is 
still in the mailbox, the source module waits a period of 
time and tries again. When the first mailbox word is 55 
found to contain all zeroes, the source module 230 
writes the two word message containing the command 
and address offset pointer into its slot in the recipient 
mailbox list at step 464 and sends an interrupt word to 
the recipient module's mailbox interrupt address at step 60 
465. 

The mail handling task in the recipient module 232 in 
response to the interrupt reads the priority mail entry. If 
the entry is a command to start a new function chart 
step, an entry is made in the queue for the function chart 65 
interpreter program. An acknowledgment is then re- 
turned to the source module 230 via an entry in its 
mailbox set and an interrupt At this time the recipient 
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module loads the source module's mailbox slot with 
zeroes preparing it to receive another message. 

"Regular mail" typically is used for transferring more 
than two words of data, although command messages 
described above also may be sent to these mailbox slots. 
For example, regular mail is used during system start-up 
to send configuration data to each module. It is also 
used during normal operations to send messages that do 
not require immediate response or action. Still referring 
to FIG. 14, when a source module 230 has several 
words of data to transfer, it assembles the data into a 
block 236 in its local memory 238. It then stores, in 
another block of memory 240, all the parameters neces- 
sary for the destination module to access the data in the 
source module's memory and acknowledge access to 
the source module 230. These parameters have a prede- 
fined format similar to that used in previous program- 
mable controllers and include the address of the data 
message, its length, the destination module's task which 
will use the data, and other information necessary to 
transfer the data. 

The two word message is then formulated in the 
source module's memory 238. The format of the mes- 
sage is shown in FIG. 12B. The first bit of the first word 
is a binary one designating this as a regular mail mes- 
sage. The next three bits are all zeroes indicating a data 
block type message as opposed to a command. The 
remaining twelve bits of the first word and all sixteen 
bits of the second word contain the beginning address of 
the transfer parameters within the source module. 

The source module 230 then notifies its mail handling 
task to send the regular mail message* As with priority 
mail, this task accesses the backplane 11 and tests hs 
regular mailbox slot in the recipient module's memory 
to make sure that it is empty. When the first word of the 
mailbox slot in the destination module is all zeroes, the 
two word regular message is written into the slot. Once 
the mailbox slot in the recipient module is loaded, the 
interrupt word is sent to the recipient module's mail 
interrupt addesss. 

The recipient module 232 upon being interrupted 
scans its mailboxes for the message. Unlike priority 
mail, the recipient module 232 does not immediately 
process the regular mail, but places the mail entry in a 
queue for handling when time permits. The handling of 
regular mail is a lower priority task as compared to the 
execution of the user control program. When the recipi- 
ent module 232 has time available, it accesses the source 
module's memory 238 via the backplane 11 and reads 
the information in the parameter block 240. The recipi- 
ent module then uses these parameters to copy the mes- 
sage data block 236 into its local memory 234 via the 
data acquisition process.described above. After copying 
the data the recipient module 232 sends an acknowledg- 
ment via regular mail to the source module 230 and 
zeroes out the regular mailbox slot The data then may 
be processed by die recipient module 232. 

With an understanding as to how data and commands 
are sent between modules, the execution of the different 
types of programs can be described. 

Program Formulation and Execution 

The present programmable controller may execute 
several general types of programs, such as a mnchinr 
operation program, independent background programs, 
interrupt subroutines and fault subroutines. The ma- 
chine operation program is developed by the user of the 
programmable controller to apply it to his particular 
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machine or process. For very complex processes, die or 50 percent of the processing time of each processor 
machine operation program is defined by a sequential module 18 for handling these tasks. The operating sys- 

function chart showing each major step of the process. tern will time-slice between the various operations of 
A separate user control program is developed to per- this type during the time allocated for them. When the 

form the functions of each step. These user control 5 allocated time expires the processing of these tasks is 
programs may comprise ladder diagram programs, as suspended until the occurrence of another interval for 
well as control programs written in higher level lan- their operation. In addition, if the processor module is 
guages. Because the preferred embodiment executes not currently executing a control program, the entire 

compiled versions of the user control programs, assem- processing time will be devoted to the background tasks 

bly language and high level languages, such as BASIC, 10 as necessary. 

may be employed to generate the source code for the The remaining processing time is allotted to the exe- 
user control program. The user control programs are cution of the machine operation program. As this task is 
assigned for execution to the different processor mod- usually time critical, the amount of time designated for 
ules. However, the present programmable controller background task processing generally is a function of 

provides the coordination of this parallel processing in 15 how much time must remain for the machine operation 

accordance with the single machine operation program. program. By carefully selecting the amount of proces- 

The independent background tasks are user programs sor time devoted to the background tasks, the operator 

that are subordinate in execu t ion to control programs can cause an execution pass through the machine opera- 

and may be used for lengthy non-time critical opera- tion program to occur at regular intervals, which may 

tions such as data acquisition from other computers and 20 be desireable in certain mnrhint* control applications, 

report generation. Interrupt routines allow high priority The machine operation program continues running 

operations to be executed upon the occurrence of a until a timed interrupt signals the start of a background 

given event, while fault routines permit a graceful re- task interval 

covery from a detected error condition in either the The present programmable controller provides an 

programmable controller 10 or the equipment being 25 improved system for executing the machine operation 

controlled. control programs, therefore, these programs will be 

Each processor module 18 has its own operating described in detaQ. A function chart program defines 

system which runs completely independent of the other the overall control process as a sequence of steps and 

modules 18 in the system and which is unaffected by the provides the mechanism for coordinating the simulta- 

processing of those other modules. Routines on the 30 neous execution of different parts of a single mnohin^ 

same processor module 18 share the resources of that operati on program in parallel by multiple program exe- 

module with the operating system deciding how much cution processor modules. As per convention each step 

processing time is allocated to each one of the simulta- is followed by a transition condition which specifies 

neously running routines. when the step is completed. A separate user control 

In order to provide orderly execution of the various 35 program, such as a ladder program, is written for each 
types of programs by a processor module, a priority step and transition of the function chart 
system is established. The highest priority level consists The machine operation; programs are written on the 
of various interrupt routines that are so time critical that intelligent terminal 24 or on a personal computer or 
their execution may never be interrupted. The next host computer connected via the local area network 28. 
level includes all other interrupts which are normally 40 These programming devices contain the necessary soft- 
run to completion except when a top priority interrupt ware so that the programmer can author the function 
or fault occurs. chart and the user control programs. The terminal or 

Interrupt routines comprise processor input inter- programming computer also compiles each user control 
rupts and selectable timed interrupts. Processor input program into machine language instructions for direct 
interrupts are started by an externally generated input 45 execution by one of the processor modules 18. If a Iad- 
and are used for high priority routines which are in- der program is used as the user defined control pro- 
tended to be executed only upon the occurrence of a gram, the technique for authoring it is the same as for 
specific input condition. To accommodate the proces- conventional programmable controllers. The only dif- 
sor input interrupts, each processor module 18 has an ference is the compilation of the completed program, 
interrupt interface 99 (FIG. 4) which receives and ban- 50 The authoring of the function chart is different for 
dies interrupt signals from external devices. The select- the present programmable controller than for previous 
able timed interrupt routines are started at regular speci- ones. The function chart is still graphically constructed 
fied intervals by the system's real time clock. A priority on the screen of the programming terminal 24 or the 
is associated with each interrupt and if more than one programming computer. The software and techniques 
interrupt is pending, the one with the higher priority 55 for doing this are similar to that practiced with conven- 
will be executed first tional programmable controllers. However, unlike pre- 

The execution of the various other program types is vious controllers, the function chart does not produce 
carried out by grouping the programs and allocating a executable code but rather generates a set of descriptor 
portion of the processing time to each group. A given files which may be thought of as directives that instruct 
amount of the execution time may be designated by the 60 the programmable controller which user control pro- 
operator during system configuration for the execution gram to execute, when to do so and which processor 
of non-time critical operations; such as background module to use. 

tasks, handling of regular inter-module messages, com- An example of a function chart is shown in FIG. 10. 

municating with other computers and miscellaneous Each processing step of the function chart is designated 

tasks. These low priority operations will be collectively 65 by a rectangle such as box 403, and each transition from 

referred to as "background tasks," although it is under- one step to another is designated by a horizontal line, 

stood that background tasks are but one type of these such as line 402. The initial step of the function chart is 

operations. Typically, the operator may select 20, 30, 40 defined by a double rectangular box as illustrated by 
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box 400. Although the initial step 400 in the FIG. 10 
function chart is at the top of the chart, it may be almost 
anywhere in the chart, with the exception of within a 
simultaneous construct, as will become apparent As 
with function charts for previous programmable con- 
trollers, step 400 includes the name of a file in memory 
(eg. FILE 1) that contains the user control program to 
be executed for that step. Unlike previous function 
charts, the box 400 also contains an indication (PI, P2, 



ditions of the initial transitions 404-406 in each branch 
are sequentially examined. The first initial transition 
which is found to be true determines which of the 
branches will then be executed. For example, if the 
condition defined by the user control program in file 13, 
transition 405, becomes true first then only the middle 
branch having step 408 will be executed. The comple- 
tion of die user control program for step 408 is indicated 
by the termination transition 411 contained in file 16. 



etc) of the processor module 18, that will execute the 10 When that transition becomes true, the program trans- 
user control program for that particular function chart fers to step 413 contained in file 6 which is executed on 
step. The present programmable controller 10 has two the second processor P2. 

processor modules 18, which are designated PI and P2, Once step 413 is completed as indicated by transition 
although additional processor modules can be inserted 414 the function chart enters what is referred to herein 
in the rack 12. The processor module 18 assigned to the IS as a "simultaneous" construct. A simultaneous con- 



initial step and the user control program file number are 
eventually stored in die system status file 201 of the 
system controller's memory (FIG. 7) so that the pro- 
grammable controller knows where to begin executing 
the machine operation program. 

The user control diagram program for step 400 for 
example is executed by the first processor module PI 
which repeatedly executes the program until a pro* 
grammed condition is met That condition is repre- 



struct comprises a plurality of function chart branches 
each containing at least one step. As the name implies 
the branches are executed simultaneously. In this case 
three processor steps 415-417 are to be executed in 
20 unison. The first step. 415 comprises the control pro- 
gram stored in file 7 which is to be executed on the first 
processor module PI. The program for the second 
branch step 416 is contained in file 8 and is to be exe- 

cuted on the first processor module PI, while the third 

seated by a transition (such as at 402) immediately 25 branch step 417 which is represented by the control 
below the box (400) in the function chart Typically the program in file 9 is assigned to the second processor 
transition 402 is defined by a single rung ladder pro- module P2. Because files 7 and 8 are both assigned for 
gram, which is executed on the same processor module, execution by the first processor module PI, the user 
eg. PI, as the associated step. The assignment of the control program contained in each of the files will be 
processor module for the transitions is automatically 30 concatenated (Le. strung together to run sequentially), 
made by the function chart editing program. If this rung This concatenation is similar to that practiced in present 
is found to be true, the execution of the user control programmable controllers. However, whereas previous 
program for step 400 ceases and the program execution programmable controllers would have to concatenate 
advances to the next function chart step 403. The por- all of the simultaneous construct files, including file 9, 
tkm of the function chart in FIG. 10 containing step 35 the present system has assigned file 9 for execution by 
400, transition 402 and step 403 is typically referred to the second processor module P2 and the remaining two 
as a "sequence** construct in that each step sequentially files 7 and 8 for execution by the first processor PI. If 
follows the other. the programmable controller 10 contained three sepa- 

Following step 403 are three separate program rate processor modules 18, the function chart step for 
branches, only one of which will be selected for execu- 40 each branch could be assigned for execution by a sepa- 
tkm depending upon the corresponding transition con- rate one of the modules. 

dition. This choice of one of many branches is referred As an example, the simultaneous construct portion of 
to as a "selection" construct The first branch includes the function diagram in FIG. 10 could control a manu- 
an initial transition 404 that is defined by the user con- factoring process where the user control program in file 
trol program contained in file 12 and processing step 45 7 controls the manufacturing process by reading various 
407 defined by the user control program contained in sensors and in response thereto activates or deactivates 
file 3. Step 407 is followed by a termination transition . various pieces of production equipment File 8 may 
condition 410 that is contained in file 15. Similarly, the consist of a control program that displays on the termi- 
middle branch contains an initial transition 405, a pro- nal 24 the status of the process being controlled by the 
ceasing step 408 followed by a termination transition 50 program in File 7. In this case, the user control program 
411. The third and final branch of the selection con- in File 9 may monitor other sensors and activate alarms 
struct consists of initial transition 406, main processing should any of these sensors indicate that given manufac- 
step 409 and a termination transition 412. Following turing errors have occurred. 

transition 412 is a GOTO statement which when exe- The transition out of the simultaneous construct sec- 
cuted causes the program to jump to the point where 55 tion is indicated by what is referred to herein as a "con- 
the rir^g"***** label appears. In this case the program verge" construct This construct contains a single tran- 
jumps to the label "BRAD" before step 419 at the bot- sition step 418 in which the user control program in file 
torn of the function chart All of the initial branch tran- 19 is executed on the second processor module P2 fot- 
sition files 12, 13 and 14 are stored on and executed by lowing each scan of the user control program in file 9. 
the same processor module (PI) as the previous tunc- 60 This converge construct transition is automatically as- 
tion chart step (403). It should be noted that since only " " * ^ 

one of the three branches of the selection construct is 
executed, they all may be processed by a single proces- 
sor module 18, in this case the first processor module 
PL Although, different branches could be designated 65 
for execution by different processor modules 18. 

Upon the completion of the previous function chart 
step 403, which proceeds a selection construct, the con- 



signed by the programming process to the same proces- 
sor (e.g. P2) as the rightmost simultaneous branch. 
When the transition 418 is true, the execution of each 
branch of the simultaneous construct ceases at the end 
of their current program scan. As noted above with 
respect to the data structure of the system controller 16 
in FIG. 7, the system support file 203 contains a mem- 
ory area for the step counters of the simultaneous por- 
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tions of the function diagram. One of these counters is 
loaded upon entry into the simultaneous section with 
the number of simultaneous processing steps in the con- 
struct. After the transition condition 418 is satisfied, this 
counter is decremented as each step 415-417 completes 
its program scan and comes to a halt When the counter 
reaches zero, all of the simultaneous steps are com- 
pleted and the transition to the next steps 419 and 421 
following the converge construct can occur. 

In prior art systems, the three function chart steps 
415-417 (FIG. 10), which were simultaneously exe- 
cuted, had to be concatenated for execution by a single 
processor and the execution of a given user control 
program occurred only once per pass through all three 



10 



larly useful in program debugging. The descriptor 430 
also identifies the next descriptor file to be used upon 
the completion of the current descriptor file and the 
processor module 18 in which it is stored; In this exam- 
ple the first descriptor 430 designates "Descriptor 2" as 
the next descriptor file which is assigned for execution 
by the first processor module PI. 

The second descriptor file 432 on FIG. 11A is gener- 
ated from the selection construct of the function chart 
in FIG. 10. The first word in the second descriptor 432 
indicates that it is a selection type and that file number 
2 contains the user control program for this step. The 
remainder of the descriptor 2 contains an array of tran- 
sitions and their corresponding next decriptor file num- 



programs. Therefore, with respect to the above exam- 15 ber and processor. For example, as shown in the func- 



ple if the control program in File 9 was an alarm func- 
tion, it would only be scanned at the completion of the 
scan of the control programs in Files 7 and 8. Whereas 
in the present multiple processor system which utilizes 
parallel processing, the user control program for the 
alarm function is repeatedly processed by its own pro- 
cessor module P2 without the intervention of other user 
control programs being concatenated with it. This pro- 
vides more frequent monitoring of time-critical condi- 
tions than is possible in a single processor system. 

The graphical representation of the function chart 
per se is not executed by the programmable controller. 
It is used, however, by the programming terminal soft- 
ware to assemble a set of data files for each of the pro- 



tion chart of FIG. 10, the first element of the array 
indicates transition file 12 and its next descriptor is de- 
scriptor 3; the second element of the array indicates 
transition file 13 and next descriptor 4; and the final 
20 entry in the array indicates transition file 14 followed by 
the next descriptor 5. 

The descriptors for the three selection branches (de- 
scriptors 3, 4, and 5) are of the sequence type and have 
the same format as the first descriptor 430. The sixth 
25 descriptor is designated as the next descriptor file num- 
ber in both descriptors 3 and 4. However, the next de- 
scriptor file number in the descriptor 5 for the third 
selection branch is the tenth descriptor for step 419 
because of the function chart GOTO statement in the 



cessor modules 18. Specifically, the function chart is 30 function chart 



reduced to a series of descriptor files that describe the 
operations of a portion of the function chart Each de- 
scriptor contains data which identifies the user control 
program for a step in the function chart, data which 
identifies the termination transition, and data which 
identifies the descriptor (and its processor module) that 
is to execute the next section of the function chart 
These descriptor files are stored in the processor mod- 
ule 18 designated in the function chart The function 



The next type of descriptor is represented by the sixth 
descriptor 434 in FIG. 11A, which is produced from the 
simultaneous construct of the FIG. 10 function chart 
The sixth descriptor 434 contains information regarding 
35 its type, the user control program file number and" a 
single transition condition file to be executed. This de- 
scriptor 434 also contains an array of the next descriptor 
files which indicate the descriptors for each of the si- 
multaneous construct branches, in this example branch 



chart interpreter software in each processor module 18 40 steps 415-417. Each of these next descriptors is exc- 
uses the respective descriptor files to control the execu- cuted by its designated processor module 18 when the 
tion of each user program. transition condition occurs. 

By way of example with reference to the exemplary The final type of descriptor file is a converge descrip- 

function chart of FIG. 10, a master descriptor file table tor which controls the execution of each simultaneously 

is generated by the programming terminal 24 as shown 45 executing branch, for example, steps 415-417 of the 

in FIG. 11A. The descriptors mil into four distinct function chart in FIG. 10. A converge descriptor is 

catagories which correspond to the function chart con- generated for each branch. The branch steps 415, 416 

struct (Le. sequence, selection, simultaneous, and con- and 417 are represented by descriptors 7, 8 and 9 in 

verge) mat generated the descriptor. Referring to FIG. 11A. AH of the converge descriptor files, as 

FIGS. 10 and 11A the first descriptor 430 represents the 50 shown by descriptions 435 and 436, contain a word 

sequence portion of the function chart, and its contents having several bits CI? designating its type and the num- 

are displayed on the right side of FIG: 11A. The first ber of the file containing the ladder program for the 

word of the descriptor contains several bits, T, which function chart step. Each converge descriptor file also 

indicate the type of the descriptor file, in this case a contains a pointer to the simultaneous counter address 

sequence type. The remaining portion of the first word 55 in the system support file 203 within the memory of the 

identifies the number of the file that contains the user system controller module 16. As will become apparent 

control program to be executed for the corresponding in the course of the description of the function chart 

function chart step. In this example, function chart step interpreter software relating to the converge portion, 

400 contains the user control program in file 1 for the the simultaneous counter is used to determine when all 

first processor module PI. The first descriptor 430 also 60 of the simultaneous branches have completed their exe- 

contains the number of the transition file which speci- cution. All of the converge branch descriptor files also 

fies the condition that is to occur before the execution of contain the number of the next descriptor file to be 

the user control program should terminate. File 11 is the executed and the processor module containing it The 

transition file number in the first descriptor 430 as speci- converge descriptor .file for the rightmost branch, in 

fied at point 402 in the function chart Two bits in the 65 this case the ninth converge descriptor 436, also identi- 

transition file number field allow the operator to desig- fies the file containing the transition condition upon the 

nate if the transition is to be forced true or false regard- occurrence of which the simultaneous execution termi- 

less of the actual state of the condition. This is particu- nates. 
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Once all of the individual descriptors are assembled 
by the programming terminal 24, they are sorted into 
groups according to the particular processor module PI 
or P2 that has been assigned to interpret them. The 
various user control programs which are specified in 5 
the descriptors are similarly sorted by processor mod- 
ule. The descriptor data and user control program files 
are then transferred by the programming terminal 24 
into the proper processor module 18 in the programma- 
ble controller 10, For example, the function chart de- 10 
scriptors 1-5, 7 and 10 and the user control programs in 
files 1-5, 7, 10-17 and 20 are assembled into a single data 
structure, as shown in FIG. 11B. This data structure is 
downloaded into the program memory area 313 of the 
first program execution processor module PI. The de- 15 
scriptors and user control program files for the remain- 
ing steps and transitions are assembled into another data 
structure as shown in FIG. 11C for the second proces- 
sor module P2. 

Once the sorted files have been downloaded into the 20 
r e sp e cti ve processor modules 18, the programmable 
controller 10 is placed in the "run" mode. Each proces- 
sor module 18 contains a function chart interpreter 
pr o gram which interprets the descriptors stored in its 
RAM 106 and executes the user control programs 25 
called for by the descriptors. When the execution of a 
machine operation step terminates, such as when the 
transition condition is satisfied, the interpreter program 
may commence interpretation of the next descriptor file 
or notify another processor module 18 that contains the 30 
next descriptor to begin interpreting it As required by 
the descriptors, one or more processor modules can 
execute different portions of the machine operation 
program simultaneously. 

FIGS. 16-19 illustrate flow charts of the program 35 
which enables each processor module 18 (FIG. 4) to 
interpret and process the various types of descriptors. 
The processing begins at step 590 at the top of FIG. 16 
with the processor module's microprocessor 98 inspect- 
ing a list of active descriptor file numbers stored in its 40 
RAM 106. This active list contains a designation of each 
descriptor file that is currently being interpreted by the 
processor module 18. If there are no descriptors listed, 
the processor module enters a dormant state at step 609 
where ft remains until it receives a processing com- 45 
maud. If the list contains an entry, the top descriptor is 
gotten off the active list at step 592 and the remaining 
entries, if any, are* moved up in the list The micro- 
processor 98 then evaluates the bits which indicate the 
type of the descriptor. Based upon the type of descrip- 50 
tor, the program at step 600 branches to one of four 
sections depending upon whether the descriptor is a 
select, simultaneous, sequence or converge type de- 
scriptor. As will be elaborated upon, there are several 
types of converge descriptors which are evaluated at 55 
branch step 607 before branching further to the specific 
routine for that converge type. 

The remaining portion of FIG. 16 is a flow chart for 
the execution of a sequence type descriptor file which 
will be described with reference to the first descriptor 60 
file 430 in FIG. 11A. This branch routine commences 
with the processor module PI at step 601 making one 
execution pass through the user control program speci- 
fied by the step file number within the descriptor. At the 
completion of the pass the file containing the transition 65 
condition indicated in the descriptor file is executed at 
decision block 602. If the condition has not happened, 
the descriptor is returned to the bottom of the active list 



in the processor RAM 106 at step 606. The program 
then returns to step 590 to get the next descriptor from 
the active list If only one descriptor is on the active list, 
the same user control program will be immediately 
executed again. This loop continues until the transition 
condition has occurred. At this point, step 603, the 
microprocessor 98 interprets the information within the 
first descriptor 430 relating to the next descriptor file to 
determine which program execution processor 18 con- 
tains the next descriptor to be interpreted. If the same 
processor module (PI) is to execute the next descriptor, 
that descriptor file is obtained from RAM 106 at pro- 
gram step 604 and placed in the active list at step 605. 
The program returns to step 590 for the microprocessor 
to check the active list and obtain the next descriptor 
for processing. 

If the next descriptor file is contained in the memory 
of another processor module 18, a command is sent at 
step 608 to that processor module via priority mail as 
described above; The command instructs the other pro- 
cessor module to begin interpreting the next descriptor. 
Once the information regarding the next descriptor has 
been transmitted to and acknowledged by the other 
processor module 18, the previously active processor 
module 18 goes into a dormant state at point 609 unless 
other descriptors remain on the active list In this dor- 
mant state a processor module 18 may execute back- 
ground and other low priority tasks as will be described. 

In the exemplary function chart of FIG. 10, the selec- 
tion construct is processed next by the first processor 
module PI. As the second descriptor 432 is a selection 
type the program branches to die routine shown in 
FIG. 17. With reference also to the schematic of the 
processor module in FIG. 4, the microprocessor 98 at 
the first step 610 of the routine' determines the number 
of elements in the array of transition condition files. An 
array pointer address in RAM 106 is set at step 611 to 
the first element in the transition condition array. The 
ladder program designated by the step file number in 
the descriptor 432 is then executed by the processor 
module P2 at point 612. 

At the completion of one scan through the user con- 
trol program, the transition condition contained within 
the file specified by the first element of the array is 
evaluated by the microprocessor 98 at step 613 to deter- 
mine if the condition is met If the transition has not 
occurred, the address contained in the array pointer is 
checked at decision block 614 to determine whether it is 
pointing to the address in RAM 106 containing the last 
element of the array. Since it is not the last element, the 
array pointer is incremented at step 615 and the pro- 
gram returns to decision block 613. The transition con- 
dition designated by the next array element is checked 
at decision block 613. Assuming that none of the transi- 
tion conditions specified in the array has occurred, this 
loop continues until the last transition condition in the 
array has been tested. At this point the execution of 
decision block 614 indicates that the array pointer is at 
the address of the last array element and the program 
advances to step 621 where the descriptor is returned to 
the bottom of the active list The processor module 
program execution then returns to step 590 (FIG. 16) to 
process the descriptor at the top of the active list 

The user control program for the select descriptor 
continues to be executed until such time as one of the 
. transition conditions in the descriptor array has oc- 
curred. At which point in time, this transition condition . 
is found to have been met at step 613 and the program 
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branches to step 616. The microprocessor 98 at step 616 
reads the array field pointed to by the array pointer 
which specifies the file number and location of the next 
descriptor to be processed. At step 617 this next descrip- 
tor specification is evaluated. If the next descriptor is 
stored on the same processor module 18 as the current 
descriptor, the microprocessor 98 will read the descrip- 
tor file from its RAM 106 at process block 618. The 
program adds the descriptor to the active list at step 620 



When the transition condition 414 has occurred, the 
processing transfers to commence the execution of the 
various function chart branches. The first element in the 
array of next descriptors, descriptor 434, is read from 
RAM 106 by the microprocessor 98 at block 634 and 
the processor module 18 for that next descriptor is then 
determined at block 635. If the module is the same as the 
current one, the next descriptor file is read from RAM 
106 at point 636 and in step 637 is added to the processor 



returns to step 590 in FIG. 16 to process the next de- 10 module's active descriptor list with any other user con- 
scriptor file. trol programs to be simultaneously executed on this 

If the next descriptor is stored in the RAM of another processor module, 
processor module 18 for execution* the program will *f one of the next descriptors is to .be executed on 
branch from decision block 617 to step 619 where the another processor module (eg. PI), the descriptor inter- 
current processor module PI sends a command message 15 pretor program branches from decision block 635 to 



by priority mail to the other processor module 18 speci- 
fying that it is to "wake up** and begin processing the 
next descriptor. This message specifies the file number 
combining the next descriptor. Upon receiving ac- 



step 639 where the current processor module P2 trans- 
mits a command via a priority mail message to that 
other module. The command instructs the other proces- 
sor module to begin interpreting the descriptor file 



knowledgment of the command message, if the active 20 stored in it The program then returns through node 640 



list is empty, the current processor module PI enters a 
dormant state at step 609 until it is notified by another 
module 18 that it is to resume processing another de- 
scriptor. 



to decision block 641 where the microprocessor 98 in 
the first processor module PI determines whether the 
last array element has been processed. If additional 
elements remain, the contents of the array pointer ad- 



Referring to the exemplary function chart of FIG. 10, 25 "f mcremented by the microprocessor 98 at step 



each of the selection branches is represented by a sepa- 
rate sequential type descriptor, the third, fourth and 
fifth descriptors in FIG. 11A. The transition from 
whichever one of the selection branches was chosen to 
the next step 413 is a standard sequential type transition. 
Specifically, if step 408 was selected for execution, the 
user control program contained in file 4 will be repeat- 
edly executed until the transition condition 411 con- 



642 and the next descriptor file number is read from the 
array at step 634. 

This process of evaluating each of the next descrip- 
tors continues for each element in the array. Once the 
30 last element has been processed by the currently opera- 
tive processor module P2 at block 641, the program 
returns to step 590 to check the active descriptor list for 
more work. 

In the exemplary function chart depicted in FIG. 10, 



tained in ffle 16 occurs. At this point the program execu- « fi^w ' 
i a<Z r*T. , . 35 the three simultaneous branches, steps 415-417, tenni- 



tion transfers to. function chart step 413. This transfer 
will be accomplished by the first processor module PI 
sending a priority mail message to the second processor 
module P2 indicating that it is to commence execution 
of the sixth descriptor 434 (FIG. 11A). 

The second processor module P2 contains a copy of 
the function chart interpreter program in its local RAM 
106. Upon receiving the command message from the 
first processor module PI, the second processor P2 adds 



nate in a converge construct The converge construct 
contains a single transition condition 418 upon the oc- 
. currence of which the execution of all the branches 
ceases. Each branch is represented by a separate de- 
40 scriptor (Descriptors 7-9) stored in the RAM 106 of the 
processor module PI or P2 which is designated by the 
user to perform respective step of the function chart 
Descriptors 7 and 8 are stored in processor PI for exe- 
*u « .m « . ^ M + M ^ A - « _ - . . . „. cution and the ninth descriptor is assigned to the second 
the sixth descriptor 434 to the bottom of its active list 45 processor P2. One of the descriptors, in this example the 



This action also M wakes up" the second processor mod- 
ule P2 if it was in the dormant state causing the module 
to enter its interpreter program at step 590 (FIG. 16). 
When the second processor module P2 begins execution 



ninth one 436 (FIG. HA) contains the transition condi- 
tion and the next descriptor file number. 

The operation of the second processor module P2 
will be initially described before discussing the simulta- 



of the sixth descriptor 434, its function chart interpreter 50 neous operation of the first processor module PI. The 
program will determine at step 600 (FIG. 16) that this ninth descriptor 436 is stored in the second processor 
descriptor is a amultaneous construct type and the pro- module P2. The interpretation of the ninth descriptor 
gram will transfer to the routine indicated by the flow 436 begins on at step 592 FIG. 16 with the processor 
chart of FIG. 18. The first program step 630 in the module's microprocessor .98 reading the descriptor 
interpretation of the simultaneous function chart de- 55 from the active list and evaluating its type. For a con- 
scriptor is the determination of the number of elements verge type descriptor the program advances to step 607 
in the array of next descriptors which indicates the where a branching occurs depending upon the particu- 
number of simultaneous steps to be performed. The lar type of converge descriptor as determined by the 
contents of array pointer address in RAM 106 is then set rnicroprocessor 98. In this case the converge descriptor 
to the address of the first element at process block 631. 60 contains the transition condition file number and the 
The user control program contained in file 6, is then program advances to node D of the routine shown in 
executed by the second processor module P2 at step FIG. 19. This converge descriptor interpreter routine 
632. At the completion of one scan of the user control begins at block 660 by the microprocessor 98 setting a 
program, the occurrence of the transition condition 414 pointer to the address of the simultaneous counter con- 
contained in file 18 is tested at decision block 633. If the 65 tained within the system support file 203 of the system 
condition has not occurred, the descriptor is returned to controller's main RAM 69 (FIG* 7). The first time 
the bottom of the active descriptor list at step 638, so through the coverage routine for a given descriptor, the 
that the user control program will be executed again. microprocessor 98 at step 661 loads the simultaneous 
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counter address with the number of simultaneous 
branches being executed, in this case three. The second 
processor module P2 then begins execution of the user 
control program from rile 9 at process block 662. At the 
completion of one pass through the user control pro- 
gram, the microprocessor 98 executes the program in 
the transition condition file specified in the ninth de- 
scriptor file 436. If this transition condition has not 
occ ur re d at step 663, the program replaces the descrip- 
tor on the active list at step 683 and then returns to step 
590 (FIG. tt>. . 

However, if the transition condition has occurred, the 
second processor module P2 at step 664 sets a flag in the 
system controller RAM 69 indicating the end of the 
simultaneous execution. While the second module P2 
has access to the system controller RAM 69, it decre- 
ments the simultaneous counter at step 665 indicating 
that the processing of its simultaneous branch has been 
completed:. Next at step 666, an evaluation of the 
counter is made by the second processor module P2 to 
determine if the counter has reached zero. If the count 
is not zero the program returns to step 590 (FIG. 16) to 
see if .other descriptors remain to process. As none are 
left for the second processor module P2, it enters a 
dormant state in step 609. 

. If all of the simultaneous execution is completed (Le. 
the count at step 666 is zero), the second processor 
module P2 at step 667 examines which processor mod- 
ule is to execute the next descriptor. If the second pro- 
cessor module P2 is to begin executing the next descrip- 
tor file, its microprocessor 98 at process block 668 reads 
the next descriptor and adds it to the active list at step 
670. Then the program returns to step 590 at the begin- 
ning of the routine in FIG. 16 where it processes the- 35 
new descriptor. If the next descriptor is to be handled 
by another processor module (e.g. PI), the routine 
branches to step 669. The second module P2 sends a 
priority mail message to that other module PI informing 
it to begin executing the next descriptor. Then the sec- 40 
ond processor module P2 enters the dormant state at 
step 609. 

As previously stated, there are several types of con- 
verge descriptors. The descriptors for the branch con- 
taining function chart steps 415 and 416 (FIG. 10) do 45 
not contain any information regarding die transition 
condition (see the eighth description 435 of FIG. 11A). 
These descriptors are stored and interpreted on the first 
processor module PL When these descriptors are evalu- 
ated by the microprocessor 98 at step 607 of FIG. 16, 50 
the interpretor program in the respective processor 
module 18 branches to node E of the routine illustrated 
in FIG. 19. In this routine an address pointer is set at 
block 680 to the simultaneous counter address in the 
system controller main RAM 69. The user control pro- 55 
gram is then executed by the microprocessor 98 at step 
681. After each user control program scan, the end flag 
address in the system controller main RAM 69 is 
checked at step 682 to determine whether or not it has 
been set, thereby indicating that the control program 60 
processing is to terminate. If the flag is not set, the 
descriptor is returned to that processor's active list at 
step 683. If the flag is set, the simultaneous counter is 
decremented twice at step 665 to indicate that the exe- 
cution of files 7 and 8 by this processor module PI is 65 
ceasing The first module PI then at step 666 checks the 
simultaneous counter and proceeds as previously de- 
scribed with regard to steps 666-670. 



As noted above, in addition to the function chart and 
user control programs the user also may define "back- 
ground tasks 9 ' for a specific processor module 18 to 
process. These programs are used to perform lengthy 
non-time critical tasks without an adverse delay in the 
operation of the function chart control program. User 
defined background tasks include report generation and 
certain subordinate control tasks. Report data regarding 
the performance of controlled equipment may be pre- 
pared for transmission via LAN 28 to a host computer. 
Such reports are not so urgent that the control of the 
equipment must be suspended while they are prepared 
and sent. The background control tasks also are used for 
lengthy calculations which are similar to those found in 
the main function chart program, but which are not 
required for real time controL 

A background task program may be invoked from a 
user control program, an interrupt routine such as a 
selectable timed interrupt, or from another background 
program. A percentage of the processing time for each 
processor module 18 has been allocated to performing 
these background tasks. Tins percentage is set by the 
user so that the execution of background tasks do not 
significantly affect the execution of the machine opera- 
tion program. Periodically the processing of the user 
control program is interrupted by the real time clock 
and the background tasks are performed for a given 
interval of time. If the end of the background task exe- 
cution period occurs before the completion of the back- 
ground program, the execution of the background task 
will be suspended and resumed during the next back- 
ground task interval. When a user control program is 
not being run on the processor module 18, the back- 
ground task may run almost continuously. In normal 
operation the background tasks will run intermittently 
to completion, however, their execution may be 
aborted by the user control program or upon the occur- 
rence of an error condition. 

Because the present programmable controller system 
has multiple processor modules 18, no single processor 
is constantly devoted to running the user control pro- 
grams. This results in time being available for the pro- 
cessor modules to perform background tasks, without 
such tasks adversely affecting the control of the manu- 
facturing equipment This is yet another benefit of the 
present parallel processing concept as applied to pro- 
grammable controllers. 

The present programmable controller 10 also pro- 
vides a two mode power loss recovery mechanism. This 
recovery mechanism is activated whenever power is 
lost during the execution of the machine operation pro- 
gram, such as due to an electric power outage. The 
operator may select during system configuration 
whether, when the power is restored after such a loss, 
the program restarts at the beginning (i.e. the initial 
function chart step) or resumes execution at the start of 
the user control program that was being executed when 
the power failed. The operator's selection of the recov- 
ery mode is stored in the system status file 201 in the 
system controller's main RAM 69. 

With reference to FIG. 3, the system status circuit 88 
detects the power beginning to fail and interrupts the 
processor section's microprocessor 66. This causes the 
microprocessor 66 to execute on interrupt subroutine 
which stores the state of each processor module's exe- 
cution in a non-volatile memory. This state data in- 
cludes the file numbers of the descriptors currently 
being executed and the descriptors on each processor 
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module's active descriptor list. Information regarding 
any background tasks being executed is also saved. 

When power is restored, if the resume mode is se- 
lected, the system controller notifies each processor 
module 18 to begin execution with the descriptor file 5 
number that was stored when the power failed. As 
noted above, the major modules in the system have 
internal batteries to keep their respective memories 
alive when the power is shut off. Therefore, the pro- 
grams and I/O tables remain stored in the modules' 10 
memories during the power outage. 

What is claimed is: 

L A programmable controller for operating a ma- 
chine to carry out a plurality of programmed functions, 
which comprises: 15 
' • a backplane bus having leads for conducting data 
signals, address signals and control signals; 
a plurality of processing means connected to said 
backplane bus, each processing means being opera- 
ble to simultaneously execute a separate user con- 20 
trol program that directs the programmable con- 
troller to operate the machine to perform a specific 
function; 

a memory means which stores program execution 
sequence data and a plurality of user control pro- 25 
grams, said memory means coupled to said plural- 
ity of processing means; 

means responsive to the program execution sequence 
data for controlling the execution of the user con- 
trol programs by said plurality of processing 30 
means; 

an I/O interface means connected to said backplane 
bus for coupling the programmable controller to 
I/O devices, and 

a system controller for supervising the access of said 35 
plurality of processing means and said I/O inter- 
face means to said backplane bus. 

2. The programmable controller as recited in claim 1 
wherein at least one of said processing means comprises 
means for interrupting the program execution by that 40 
processing means in response to an interrupt signal from 
an apparatus that is external to said programmable con- 
troller. 

3. The programmable controller as recited in claim 2 
wherein at least one of said processing means further 45 
comprises means for executing an interrupt program 
routine after the program execution is interrupted by 
said means for interrupting. 

4. The programmable controller as recited in claim 1 
wherein said program execution sequence data com- 50 



prises a series of descriptors, each descriptor containing 
an identification of a user control program, an identifi- 
cation of a transition condition which indicates when 
the execution of the identified user control program is 
to terminate, and an identification of the next descriptor 
to be processed and which processing means will pro- 
cess the next descriptor. 

5. The programmable controller as recited in claim 4 
wherein each of said processing means includes means 
for interpreting the descriptors* 

6. The programmable controller as recited in claim 4 
wherein each of said processing means includes means 
for forcing the transition conditions to be either true or 
false regardless of the actual state of the condition. 

7. The programmable controller for operating a ma- 
chine to carry out a plurality of programmed functions, 
which comprises: 

a backplane bus having leads for conducting data 
signals, address signals and control signals; 

a plurality of processor means connected to said 
backplane bus, each processor means having a 
memory for storing user control programs for exe- 
cution on that processor means and program exe- 
cution sequence data comprising a plurality of de- 
scriptors each identifying a user control program, a 
transition condition which indicates when the exe- 
cution of the user control program should termi- 
nate, and the next user control program to be exe- 
cuted and which processor means is to execute the 
next user control program, each of said processor 
means having means to transmit program execution 
commands to other processor means; 

an I/O interface means coupled to said backplane bus 
for coupling I/O devices to the programmable 
controller; and 

means for controlling access to said backplane bus by 
said plurality of processor means and said I/O 
interface means. 

8. The programmable controller as recited in claim 7 
wherein said program sequence data further comprises 
a designation of one of the user control programs to be 
executed initially at the start of program execution. 

9. The programmable controller as recited in claim 7 
further comprising means for saving program execution 
status data for each processor means upon an electrical 
power failure so that programs which were executing 
when the power failure occurred can resume executing 
upon restoration of electrical power. 
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